Windows 11

Journaux liées à cette note :

Système de mise à jour d'Android, Chrome OS, MacOS et MS Windows #MacOS, #CoreOS, #linux, #windows, #distribution-linux

Cette note fait partie de la série de notes : "J'ai étudié et testé CoreOS et je suis tombé dans un rabbit hole 🙈".

Note précédente : "Ajout de packages dans des distributions atomiques".

Chrome OS et Android implémentent la stratégie de double partition A/B (seamless) system updates.
Cette technologie offre des mises à jour complètement transparentes en arrière-plan et un redémarrage immédiat.
En revanche, contrairement à la solution CoreOS (méthode détaillée dans cette note), cette méthode a pour inconvénient de consommer deux fois plus d'espace de stockage.

MacOS s'appuie sur les snapshots de son filesystem APFS (fonctionnalité qu'offre aussi btrfs). Cela garantit un retour en arrière rapide vers la version antérieure si des problèmes surviennent.
En revanche, l'upgrade se termine durant le reboot, pouvant prendre de 2 à 5 minutes, alors que le redémarrage reste instantané avec Chrome OS, Android, CoreOS ou Fedora Silverblue.

Comme d'habitude, je n'arrive pas à trouver des informations précises sur le fonctionnement interne de MS Windows 😔. D'après Claude Sonnet 4, le système de mise à jour de Windows 10 et Windows 11, baptisé Unified Update Platform (UUP), semble plutôt daté : pas d'A/B (seamless) system updates, absence d'atomicité, installation longue lors du reboot (10 à 30 minutes), possibilité d'échec en cours de processus, rollback complexe, aucun système de snapshot comparable à MacOS. J'ai du mal à croire ce bilan tellement catastrophique, ce qui m'amène à questionner sur l'exactitude des informations rapportées par Claude Sonnet 4.

D'après cette documentation particulièrement riche et mes recherches complémentaires, je pense que la stack libostree + composefs (avec zstd:chunked ) tel qu'implémenté dans Fedora CoreOS est probablement la technologie de mise à jour la plus avancée actuellement disponible.

Avant de présenter le fonctionnement du système de mise à jour de Fedora CoreOS en 2025, je vais retracer l'évolution technique de cette solution.

Note suivante : "CoreOS de 2013 à 2018".

Confirmation du bon fonctionnement de mon environnement de développement sous Windows, avec WSL2 qui se comporte comme Ubuntu #windows, #dev-kit

Je précise que je n'ai pas eu l'occasion de tester l'installation sous Windows, hier j'ai essayé, mais je n'ai pas réussi à installer WSL2 sous Windows dans un Virtualbox lancé sous Fedora. Je suis à la recherche d'une personne pour tester si mes instructions d'installation sont valides ou non.

source

Merci à Alexandre 🤗 qui a pris le temps de tester l'installation sous WSL2 du playground que j'ai présenté dans "Playground qui présente comment je setup un projet Python Flask en 2025".

Le playground : https://github.com/stephane-klein/mise-python-flask-playground

Après quelques petites corrections https://github.com/stephane-klein/mise-python-flask-playground/commits/main/ Alexandre a réussi avec succès à installer et lancer tous les services sous Windows 11 avec WSL2.

C'est une très bonne nouvelle 🙂.

Cela ajoute une « corde à mon arc ». Jusqu'à présent, je précisais bien que mes development kit n'étaient pas compatible MS Windows. Je le mentionnais même dans mes annonces d'embauche, pour ne pas surprendre les candidats.

Maintenant, mes environnements de développement sont compatibles Linux, MacOS, et Linux 🙂.

Je n'ai pas réussi à installer WSL2 sous Windows dans un Virtualbox lancé sous Fedora #WSL, #windows, #VirtualBox

Après avoir réussi à lancer Windows 11 sous ma Fedora dans VirtualBox (voir 2025-02-04_1646), j'ai essayé d'installer et de lancer WSL2, mais je n'ai pas réussi 🙁.

Je suis resté bloqué à cette étape :

vagrant@WIN11 C:\Users\vagrant>wsl --install
Ubuntu est déjà installé.
Lancement de Ubuntu...
Installing, this may take a few minutes...
WslRegisterDistribution failed with error: 0x80370102
Please enable the Virtual Machine Platform Windows feature and ensure virtualization is enabled in the BIOS.
For information please visit https://aka.ms/enablevirtualization
Press any key to continue...
L’opération a réussi.

Même avec ces options :

    win11.vm.provider "virtualbox" do |vb|
      vb.customize ["modifyvm", :id, "--nested-hw-virt", "on"]
      vb.customize ["modifyvm", :id, "--paravirtprovider", "kvm"]
      vb.customize ["modifyvm", :id, "--cpu-profile", "host"]
      vb.cpus = 4
      vb.memory = 16000
    end
  end

Windows ne semble pas vouloir lancer Hyper-v dans un VirtualBox.

J'ai essayé différents paramètres pour --paravirtprovider, sans succès.

Si quelqu'un a la solution, je suis preneur ! (contact@stephane-klein.info).

Journal du mardi 04 février 2025 à 16:46 #windows, #VirtualBox, #WSL, #JaiDécouvert

Je souhaite créer un playground d'un development kit pour Python + PostgreSQL (via Docker) + Flask + Flask-Migrate, basé sur Mise.

J'ai la contrainte suivante : le development kit doit fonctionner sous MS Windows !

Je me dis que c'est une bonne occasion pour moi de tester Windows Subsystem for Linux 🙂.

Problème : je ne possède pas d'instance MS Windows.

#JaiDécouvert que depuis 2015, Microsoft met à disposition des ISOs officiels de MS Windows :

J'ai testé dans ce playground le lancement d'une Virtual machine MS Windows avec Vagrant : https://github.com/stephane-klein/vagrant-windows-playground.

Cela a bien fonctionné 🙂.

J'ai aussi découvert le repository windows-vagrant qui semble permettre de construire différents types d'images MS Windows avec Packer. Je n'ai pas essayé d'en construire une.